With the emergence of 3G mobile telephony, new packet-based communication technologies have been developed for communicating multimedia content. For example, technologies such as GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) support wireless multimedia telephony services involving packet-switched communication of data representing images, text, documents, animations, audio files, video files, etc., in addition to traditional circuit-switched voice calls.
Recently, a network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP), to provide multimedia services for mobile and fixed clients in the packet domain. IMS is generally a platform for multimedia services based on IP transport, more or less independent of the access technology used. Basically, any types of access networks with packet-switching capabilities can be connected to an IMS network, including networks based on GPRS/UMTS, WLAN, fixed broadband, cable television, DSLAM, Ethernet, etc. The concept of IMS networks is well-known in the field of telecommunication, and the various functions of the IMS network elements are not necessary to describe here to understand the present invention.
A specification for session setup has been defined called “SIP” (Session Initiation Protocol), which is an application-layer signalling protocol for controlling sessions over a packet-switched logic. SIP is independent of the underlying data transport technologies, and is generally used by session managing nodes in IMS networks in support of multimedia services.
One set of services that can be employed by means of an IMS network is the so-called “Presence” services. Presence services basically involve the publishing of “presence data” of a user to make it available for other users and applications, which can also be used to control further services in turn. Presence data basically defines the state or situation of a user and his/her equipment in some predefined respect.
The IMS architecture is based on a layered network structure where different communication functions are implemented in three main layers: an access layer, a session control layer and a service layer. The services in the service layer are basically independent of the technology and protocols used in the access layer. This layered architecture enables convergence of networks as various different access networks, both fixed and cellular/mobile, can be connected to one and the same IMS session management layer, sometimes referred to as the “IMS core”.
Some services in the service layer, as well as certain session management functions in the session control layer, may need or even require information on the geographical location of a calling party. Examples of such services in IMS networks include presence services, messaging and various information services including GIS (Geographic Information System), presence-enabled buddy lists, “yellow pages” with regional information, and the “friend and family finder” function. Further, the setting of user policies, charging tariffs and other communication parameters may also depend on the user's current location.
In particular, location information may be of vital importance for calling subscribers in situations of emergency, such as accidents and diseases. An emergency call is typically first routed to an emergency centre which then connects the caller further to a local service station or the like depending on the current situation, e.g. a doctor, hospital, fire station or the police.
The requirements for emergency services are subject to regulations prevailing in different countries and regions. Typically, it is required that the telephony system can provide relevant location information in order to certify the location of the calling party. Firstly, an incoming emergency call should be connected to a suitable emergency centre being reasonably close to the caller, in the US referred to as the Public Safety Alarm Point (PSAP), which may be critical in some situations. Secondly, the caller may not, for whatever reason, be able to provide correct information regarding his/her whereabouts to the emergency centre or service station, at least not immediately, which may of course be crucial for taking further actions rapidly.
FIG. 1 illustrates a subscriber terminal A connected to a traditional fixed telephony network 100 by means of a local exchange LE 102. Network 100 routes an incoming emergency call from subscriber A to an emergency centre 104. Network 100 further includes a location database 106 holding geographic location information on subscribers fixedly connected to the network 100, including subscriber A, e.g. in the form of local street addresses or the like.
It is typically required in fixed public networks that local exchanges therein ensures that a “calling party identifier” is included in emergency calls when routed to an emergency centre. In the present example, local exchange 102 has knowledge of subscriber terminal A being connected to a specific input line in the exchange 102, which is associated with a specific calling party identifier. The local exchange 102 thus supplies the calling party identifier of subscriber terminal A when transmitting the emergency call to emergency centre 104. Location database 106 stores the geographic location associated with the calling party identifier. Emergency centre 104 can thus retrieve that location from location database 106 by means of the calling party identifier received with the emergency call, as illustrated by the dashed arrows.
In a cellular network, a serving Mobile Switching Centre MSC can include location information in emergency calls from mobile terminals. The location information may be a cell identity (ID) or even more accurate information in the form of geographic coordinates derived by positioning functions employed in the network. A Mobile Positioning System (MPS) is often implemented in mobile networks, e.g. using signal strength and/or time alignment measurements on signals from different base station sites, known as “triangulation”, to calculate the position of a mobile terminal. The location information may be sent once in an emergency call, or be constantly updated during the call if the calling terminal is moving.
Alternatively, a satellite based navigation system such as GPS (Global Positioning System) or Gallileo can be utilised. The terminal must then of course be equipped with a GPS receiver that must be able to receive the satellite signals. Moreover, the terminal must have a function to communicate the positioning result in a comprehensive and trusted manner to a session node handling the call in the session management layer. Dedicated positioning systems such as GPS typically takes some time to determine the position, even several minutes. Local regulations often define a maximum allowed delay for providing the location to the emergency centre, usually within a few seconds.
Today, different methods for determining the location are available in different types of access networks. For example, if a private LAN (Local Area Network) is connected to an end point of a public access network, a number of new end points within the LAN are effectively introduced. Thus, the geographic location of specific end points within the LAN are typically unknown to the public network, unless they are specifically reported to the public network for storage in a location database or the like.
FIG. 2 illustrates schematically three basic types of wire line access networks that are used today for IP-based broadband access, which are shown connected to a backbone network 200 such as the Internet. A first network type 202 is connected to a backbone network 200 by means of a gateway 202a, and is based on DSL (Digital Subscriber Line) technology. A switching node 202b referred to as DSLAM (DSL Access Multiplexor) is connected to a plurality of individual dedicated subscriber lines, where each subscriber uses a DSL type modem (modulator/demodulator) 202c (e.g. ADSL) for modulating signals from one or more connected IP terminals onto a conventional dual line copper wire, i.e. telephone wire. The DSLAM node 202b converts modulated signals received on each subscriber line into Ethernet language, and vice versa.
A second network type 204 is likewise connected to a backbone network 200 by means of a gateway 204a, and is based on cable television technology using coaxial or HFC (Hybrid Fibre Coax) antenna cables. A switching node 204b referred to as CMTS (Cable Modem Termination system) connects a common TV cable 204c, to which a plurality of cable modems 204d are connected for modulating signals from connected IP terminals onto the TV cable. The CMTS node 204b converts modulated signals received on the common TV cable 204c into Ethernet, and vice versa. The location of the specific end points is typically unknown, unless such information is added at the end points.
Finally, a third network type 206 is also shown connected to the backbone network 200 by means of a gateway 206a, based on Ethernet communication technology throughout. A plurality of switching nodes 206b are interconnected in a trellis-like structure. Further, a plurality of IP terminals 206c are shown connected to at least some of the switches 206b. It should be noted that the three access network types are illustrated here merely as basic examples of network architectures which may be combined in any suitable manner. Further, it is possible to, e.g., create a DSL type network using coaxial or HFC cables in the physical transport layer.
In this description, the above network types will be briefly referred to as “DSL network”, “Cable network” and “Ethernet network”, respectively. However, these access technologies more or less share the problem of obtaining reliable geographic location information for calling subscribers using ambulant terminals, and there are no built-in functions to this end as yet.
Even if one end point can be distinguished from other ones, each known end point must somehow be associated with location information such as a street address or geographical coordinates or the like, requiring that a location database is properly maintained for the known end points. Typically, the subscriber himself/herself must provide mapping information for a network address currently used, e.g. a layer 2 IP address, and a corresponding location, e.g. street address, for storage in the location database. It is therefore impossible to validate that the stored mapping information is correct for each call, particularly when subscribers move between different end points. Thus, such a location database is troublesome to maintain and still not wholly reliable.
Hence, the problem of determining the location of a terminal connected to a more or less fixed end point in a broadband network lies in certifying the location of that end point. In addition, the obtained location information must sometimes also be used for routing the call to the proper party, particularly in the case of emergency calls. This must also be done quite fast, preferably within a few seconds, often being subject to regulations. It may also be desirable to certify a location given in a process involving a terminal that is not wholly trustworthy, e.g. with respect to its functions or authenticity, etc.
In regard to the background description above, it is desirable to provide reliable location information in a call from a calling party connected to an access network, e.g. according to any of the above-described network types. It is particularly desirable to obtain reliable location information for emergency calls in a reasonably swift manner, e.g. in order to satisfy prevailing emergency requirements. It is also desirable to enable the swift selection of a suitable emergency centre to which an emergency call is to be routed, depending on the location of the calling subscriber.
Using an IMS network with separated access and session management layers that support several access network types (IP networks), e.g. using newly conceived access technologies and protocols, it is not evident how to provide location on calling parties in a sufficiently swift and reliable manner. The challenge lies in both how to perform the location determination and how to validate if it is trustworthy. In addition, the situation may become even more complicated when several different network operators are involved. The operator of an access network is not necessarily, and will often actually not be, the same as the operator of the IMS network, including the IMS Core.
For example, it is a problem with existing solutions for fixed broadband networks that in many access network types such as Cable networks or Ethernet networks, the existing solutions for location determination use pre-stored location information originally provided by the end users themselves, with no or very limited control mechanisms. Therefore, it is a problem that the network operator, typically being responsible according to regulations for routing emergency calls correctly, cannot verify if the location of a caller given by an access network is correct, if the access network depends on end user-provided, i.e. “unreliable”, location information.
Another problem is that, even within an access network, the location can often be obtained in different ways with different reliability. For example, in the case of a mobile access network, a user client in the mobile terminal may be adapted to add an identity of the current cell in a header field such as, e.g., an existing header field called “P-Access-Network”. However, a mobile terminal cannot always be trusted since it may be attacked by viruses or otherwise out of order, in a way that affects the above function.